約 6,060,890 件
https://w.atwiki.jp/anison-research/pages/107.html
フュージョン 参考 Driving My Way GEOMETRIC DANCE 幾望の月 お願い！シンデレラ -山本真央樹 Remix-
https://w.atwiki.jp/touhouvision/pages/52.html
Advanced Starterカードリスト 概要 2012年8月11日 コミックマーケット８２にて頒布開始、全100種。 パッケージイラストは西行寺 幽々子＆レミリア・スカーレット。 絶版になった第一弾、第二弾、第三弾、第四弾、第六弾、第八弾から発売当時の環境に合ったと思われるカードを収録。 優秀なカードが多く収録されているので、初めてVISIONを始めるプレイヤーは買っておきたいスターター。但し、キャラクターカードは５種しかないためこれだけでゲームを始めるには向かない。 Based Starterに収録されなかった守矢神社や恐ろしい波動をはじめ、長らく再録の望まれていた是非曲直庁の威令などが収録されている。 キャラクターカード（５種） SP.032：リリーホワイト SP.035：魂魄 妖忌 SP.039：レイラ・プリズムリバー SP.040：プリズムリバー伯 SP.010：封獣 ぬえ スペルカード（４５種） SP.036：夜符「ナイトバード」 No.053：仙符「鳳凰卵」 PR.019：木符「シルフィホルン」 No.104：管霊「ヒノファンタズム」 No.110：夢符「二重結界」 PR.103：禁薬「蓬莱の薬」 SP.041：洪水「ウーズフラッディング」 No.203：河童「お化けキューカンバー」 No.209：霊符「夢想封印 散」 No.215：紅符「スカーレットシュート」 SP.011：神祭「エクスパンデッド・オンバシラ」 SP.042：神符「杉で結ぶ古き縁」 No.422：闇符「ダークサイドオブザムーン」 No.423：冬符「フラワーウィザラウェイ」 No.425：鳥符「ヒューマンケージ」 No.426：豊符「オヲトシハーベスター」 No.429：騒符「ルナサ・ソロライブ」 No.430：騒符「リリカ・ソロライブ」 No.431：騒符「メルラン・ハッピーライブ」 No.432：大合葬「霊車コンチェルトグロッソ」 No.434：疵痕「壊されたお守り」 No.435：譫妄「イントゥデリリウム」 No.436：幻惑「花冠視線（クラウンヴィジョン）」 No.437：水符「河童のポロロッカ」 No.438：式神「橙」 SP.043：難題「燕の子安貝 -永命線-」 No.441：表象「夢枕にご先祖総立ち」 No.442：天呪「アポロ13」 No.444：要石「天地開闢プレス」 No.445：禁弾「カタディオプトリック」 No.591：釣瓶「ウェルディストラクター」 No.593：ナマズ「オール電化でエコロジーじゃ！」 No.594：秋符「フォーリンブラスト」 No.595：毒符「樺黄小町」 No.596：妬符「グリーンアイドモンスター」 No.598：国符「三種の神器 剣」 No.602：幻世「ザ・ワールド」 No.603：転覆「道連れアンカー」 No.604：転世「一条戻り橋」 No.605：鬼声「壊滅の咆哮」 No.607：熱符「ブレイクプロミネンス」 No.609：難題「蓬莱の弾の枝 -虹色の弾幕-」 No.611：「反魂蝶」 No.613：錬丹「水銀の海」 No.615：恨弓「源三位頼政の弓」 コマンドカード（５０種） No.085：近接戦闘 No.089：永夜の術 No.090：対抗魔術 SP.037：断罪裁判 No.141：人形の森 No.145：白玉楼の幻闘 SP.031：少女密室 SP.038：反転攻勢 No.150：紅い飼い主 No.229：小さな脱出劇 No.230：魔導書 No.234：洩矢の王国 No.238：月旅行計画 No.245：月都万象展 No.247：迷ひ家 No.278：守矢神社 No.285：憑依 No.290：光の春 No.294：恐ろしい波動 No.298：リザレクション No.446：障壁 No.447：蟲の知らせ No.448：密命 No.450：後天性変異 No.452：ボーダーオブライフ No.454：逆さ虹 SP.044：精神の海 No.458：パペットリッター No.459：祇園様の剣 No.462：是非曲直庁の威令 No.464：召喚魔術 No.466：悠久の月明 No.468：奪われた叡智 No.469：満月の爆発 No.470：横溢 No.617：不意打ち No.618：落とし穴 No.619：離剣の見 No.620：転化 No.624：要石 No.625：衛星カフェテラス No.626：正体不明の種 No.627：胡蝶夢丸 No.629：ブロッケンの妖怪 No.630：五つの難題 No.631：異郷の薬売り No.633：逢魔が時 No.634：イリュージョナリィブラスト No.636：死霊の復活 No.640：地霊殿 プロモーションカード PR.111：激突
https://w.atwiki.jp/wikiska/pages/318.html
Song Eastern Standard Time A.K.A.：Reflections Of Don D 作曲者：Don Drummond Duke Reid? オリジナル『Eastern Standard Time』 アーティスト：Don Drummond プロデュース：Duke Reid? 年：1964 7inch：FDR-3031（） 1st solo Don Drummond 一部のクレジットでは、アーティストがTommy McCookやThe Skatalitesになっている。 収録時間は3分06秒。 収録作品 Various Artist 『Music Is My Occupation?』 1989 Various Artist 『Tribute To The Skatalites?』 1991 Various Artist 『Trojan Instrumentals Box Set?』 1999 Various Artist 『Rough & Tough, The Story Of Ska 1960-1966?』 2002 ショートバージョン『Eastern Standard Time』 アーティスト：Don Drummond プロデュース：Duke Reid? 年：1964 オリジナルと同じテイクだが、早めにフェードアウトしている。 収録時間は2分45秒。 収録作品 Don Drummond 『Best Of Don Drummond』 19 ショートバージョン『Eastern Standard Time』 アーティスト：Don Drummond プロデュース：Duke Reid? 年：1964 オリジナルと同じテイクだが、さらに早めにフェードアウトしている。 収録時間は2分33秒。 収録作品 Various Artist 『Foundation Ska』 1997 カバー『Reflections Of Don D』 アーティスト：Johnny Dizzy Moore? プロデュース：Joe Gibbs? 年：19 収録作品 Various Artist 『Trojan Instrumentals Box Set?』 1999 ライブバージョン『Eastern Standard Time』 アーティスト：The Skatalites プロデュース：Herbie Miller? 年：1983 Arnold Breckenridge?がトランペット、Bubbles Cameron?がトロンボーンで参加。 収録作品 The Skatalites 『Stretching Out』 1987 ライブバージョン『Eastern Standard Time』 アーティスト：The Skatalites プロデュース：[[]] 年：1996 収録作品 The Skatalites 『Guns Of Navarone』 2001 セルフカバー『Eastern Standard Time』 アーティスト：The Skatalites プロデュース：Nathan Breedlove?, Bill Smith?, Shay?, The Skatalites 年：1997 1st solo Will Clark? 2nd solo Roland Alphonso? 3rd solo Lester Sterling? Nathan Breedlove?がトランペットで、 Will Clark?がトロンボーンで、Devon James?がギターで、Bill Smith?がピアノ?で、それぞれ参加している。 収録作品 The Skatalites 『Ball Of Fire』 1997
https://w.atwiki.jp/satoschi/pages/343.html
Central Narrow Bantu S languages 中央狭義バントゥーS諸語 *Retired This page has been retired. Niger-Congo Atlantic-Congo【alv】 Volta-Congo Benue-Congo Bantoid Southern Bantoid Narrow Bantu Central Narrow Bantu Central Narrow Bantu S languages Chopi (S.60) —チョピ諸語 Chopi【cce】—チョピ語 Gitonga【toh】— Nguni (S.40) —ングニ諸語 North Ndebele【nde】—北ンデベレ語 Swati【ssw】—スワティ語 Xhosa【xho】—コサ語 Zulu【zul】—ズールー語 Shona (S.10) —ショナ諸語 Dema【dmx】—デマ語 Kalanga【kck】—カランガ語 Manyika【mxc】—マニィカ語 Ndau【ndc】—ンダウ語 Nambya【nmq】—ナンビャ語 Shona【sna】—ショナ語 Tawara【twl】—タワラ語 Tewe【twx】—テウェ語 Sotho-Tswana (S.30) —ソト＝ツワナ語〔ソト＝チュワナ語〕 Kgalagadi — Kgalagadi【xkv】— Lozi【loz】—ロジ語 Sotho —ソト諸語 Birwa【brl】—ビルワ語 Northern —北部諸語 South Ndebele【nbl】—南ンデベレ語 Pedi【nso】—ペディ語 Southern —南部諸語 Sotho, Southern【sot】—南部ソト語 Tswana —ツワナ語〔チュワナ語〕 Tswana【tsn】—ツワナ語 Tswapong【two】— Tswa-Ronga (S.50) —ツワ＝ロンガ語 Ronga【rng】—ロンガ語 Tswa【tsc】—ツワ語 Tsonga【tso】—ツォンガ語 Venda (S.20) —ヴェンダ語〔ベンダ語〕 Venda【ven】—ヴェンダ語
https://w.atwiki.jp/dslbookwip/pages/12.html
このページはhttp //martinfowler.com/dslwip/Intro.htmlからの引用です | DSL-WIP Home | WORK-IN-PROGRESS - this material is still under development An Introductory Example Last significant update 06 Aug 07 Contents Miss Grant s Controller The State Machine Model Programming the Controller with a Domain Specific Language Languages and Model Using Code-Generation Using Language Workbenches Visualization Picking up this book, you may be asking yourself such questions as what is a DSL , how does it fit in with my usual development work and why would I find such a thing useful ? This chapter begins by looking at these questions. I ll talk about what a DSL is, the various types of DSL, the reasons to use a DSL, and the broader topic of language processing. At this stage I won t talk about how the various styles of DSL work - we ll get into that later. Miss Grant s Controller As is usual for me, I ll base this discussion on an example, as I find that a concrete example usually makes it easier to follow an abstract topic like this. Let s imagine a company that makes systems to control access to secret compartments. Their customers are people who are bored with numeric keypads and security codes, instead preferring something recalling bad movies set in gothic castles. So Miss Grant has a secret compartment in her bedroom that is normally locked and concealed. To open it she has to close the door, open the second draw in her chest, turn her bedside light on - and then the secret panel is unlocked for her to open. Mr G has the same basic system for a panel in his bedroom. He has to open his bathroom door and turn on the main light which allows him to open the panel. The panel reveals a safe, but it has an overriding lock that cannot be opened unless he turns his light off and on again. Mr C has a compartment in his office, he has to close his main door, take a picture off the wall, turn his desklight on three times, open the top draw of his filing cabinet, turn the desklight off - and then the panel s unlocked. If he forgets to turn the desklight off, he wants an alarm to sound. Although this example is deliberately whimsical, the underlying point isn t that unusual. What we have is a family of systems which share most components and behaviors, but have some important differences. In this case we have some kind of controller software which communicates with various devices around the room. The variability is in the sequence of actions that can be carried out and the actions that the software does as a result of these sequences. We want to arrange things so that the company can install a new system with the minimum of effort, so it must be easy for them to program the sequence of actions into the controller. Looking at their many customers they realize there is a common theme to the way they behave. The various devices send events as they are manipulated. The system reacts differently to events depending on the recent sequence of events. This style of thinking about behavior is that of a state machine. Thus it makes sense to build a model of a state machine that can be programmed for individual customers at each site. That way the general behavior can be resued for each customer and setting up a new customer just means writing the specific things for each case. The software is written in java, running on a job lot of toasters they picked up from a failed dot com. The State Machine Model There are many varieties of state machine models around, this one is simple, and with a little twist for the this particular case. There are frameworks out there to run state machines, but we can do with something much simpler that s more suited to this particular domain. By doing this we give up some power for an easier job working with it. This issue isn t really part of the DSL discussion so I won t explore it further. To help understand how the state machine model works, let s take Miss Grant s system. Figure 1 State diagram for Miss Grant The system has a controller that receives events and commands from the various devices scattered around. Each event and command has a four letter code that s the actual signal sent through the communication channels. I want to refer to these in the controller code with symbolic names, so I create event and command classes with a code and a name. I keep them as separate classes (with a superclass) as they play different roles in the controller code. class AbstractEvent... private String name, code; public AbstractEvent(String name, String code) { this.name = name; this.code = code; } public String getCode() { return code;} public String getName() { return name;} public class Command extends AbstractEvent public class Event extends AbstractEvent Figure 2 Class diagram of the state machine framework [TBD Add reset event association to class diagram] The key to the structure is that state class. Each state class keeps track of the events and commands. class State... private String name; private List Command actions = new ArrayList Command (); private Map String, Transition transitions = new HashMap String, Transition (); public void addTransition(Event event, State targetState) { transitions.put(event.getCode(), new Transition(this, event, targetState)); } class Transition... private final State source, target; private final Event trigger; public Transition(State source, Event trigger, State target) { this.source = source; this.target = target; this.trigger = trigger; } public State getSource() {return source;} public State getTarget() {return target;} public Event getTrigger() {return trigger;} public String getEventCode() {return trigger.getCode();} The state machine holds on to its start state. class StateMachine... private State start; public StateMachine(State start) { this.start = start; } Any other states in the machine are then those that are reachable from this state. class StateMachine... public Collection State getStates() { List State result = new ArrayList State (); gatherForwards(result, start); return result; } private void gatherForwards(Collection State result, State start) { if (start == null) return; if (result.contains(start)) return; else { result.add(start); for (State next start.getAllTargets()) { gatherForwards(result, next); } return; } } class State... Collection State getAllTargets() { List State result = new ArrayList State (); for (Transition t transitions.values()) result.add(t.getTarget()); return result; } There is one particular wrinkle to this problem. These controllers have a particular nature to them in that most of the time they are in their start state, which is effectively an idle state. There are events that advance the state machine, and there are events that take you back to that start state. For this case opening the door always takes you back to the start. So I let the machine keep track of reset events. class StateMachine... private List Event resetEvents = new ArrayList Event (); public void addResetEvents(Event... events) { for (Event e events) resetEvents.add(e); } I don t need to have a separate structure for reset events here. I could handle this by simply declaring extra transitions on the state machine like this class StateMachine... private void addResetEvent_byAddingTransitions(Event e) { for (State s getStates()) if (!s.hasTransition(e.getCode())) s.addTransition(e, start); } I prefer explicit reset events on the machine becuase that better expresses the intention of what I m trying to do. While it does complicate the machine a bit, it keeps the clarity of my intention of how a general machine is supposed to work, as well as keeping the intention of how a particular machine is defined. With the structure out of the way, now lets move on to the behavior. As it turns out, it s really quite simple. The controller has a handle method that takes the event code it receives from the device. class Controller... private State currentState; private StateMachine machine; public CommandChannel getCommandChannel() { return commandsChannel; } protected CommandChannel commandsChannel; public void handle(String eventCode) { if (currentState.hasTransition(eventCode)) transitionTo(currentState.targetState(eventCode)); else if (machine.isResetEvent(eventCode)) transitionTo(machine.getStart()); // ignore unknown events } private void transitionTo(State target) { currentState = target; currentState.executeActions(commandsChannel); } class State... public boolean hasTransition(String eventCode) { return transitions.containsKey(eventCode); } public State targetState(String eventCode) { return transitions.get(eventCode).getTarget(); } public void executeActions(CommandChannel commandsChannel) { for (Command c actions) commandsChannel.send(c.getCode()); } class StateMachine... public boolean isResetEvent(String eventCode) { return resetEventCodes().contains(eventCode); } private List String resetEventCodes() { List String result = new ArrayList String (); for (Event e resetEvents) result.add(e.getCode()); return result; } It ignores any events that are not registered on the state. For any events that are recognized, it transitions to the target state and executes any commands defined on that target state. Programming the Controller with a Domain Specific Language Now I ve implemented the state machine model, I can now program Miss Grant s controller like this. Event doorClosed = new Event( doorClosed , D1CL ); Event drawOpened = new Event( drawOpened , D2OP ); Event lightOn = new Event( lightOn , L1ON ); Event doorOpened = new Event( doorOpened , D1OP ); Event panelClosed = new Event( panelClosed , PNCL ); Command unlockPanelCmd = new Command( unlockPanel , PNUL ); Command lockPanelCmd = new Command( lockPanel , PNLK ); Command lockDoorCmd = new Command( lockDoor , D1LK ); Command unlockDoorCmd = new Command( unlockDoor , D1UL ); State idle = new State( idle ); State activeState = new State( active ); State waitingForLightState = new State( waitingForLight ); State waitingForDrawState = new State( waitingForDraw ); State unlockedPanelState = new State( unlockedPanel ); StateMachine machine = new StateMachine(idle); idle.addTransition(doorClosed, activeState); idle.addAction(unlockDoorCmd); idle.addAction(lockPanelCmd); activeState.addTransition(drawOpened, waitingForLightState); activeState.addTransition(lightOn, waitingForDrawState); waitingForLightState.addTransition(lightOn, unlockedPanelState); waitingForDrawState.addTransition(drawOpened, unlockedPanelState); unlockedPanelState.addAction(unlockPanelCmd); unlockedPanelState.addAction(lockDoorCmd); unlockedPanelState.addTransition(panelClosed, idle); machine.addResetEvents(doorOpened); I look at this last bit of code as quite different in nature to the previous peices. The earlier code described how to build the state machine model, this last bit of code is about how to configure that model for one particular controller. You often see divisions like this. On the one hand is library, framework, or component implementation code; on the other is configuration or component assembly code. Essentially it is the separation of common code from variable code. We structure the common code in a set of components that we then configure for different purposes. Here is another way of representing that configuration code. stateMachine start = idle event name= doorClosed code= D1CL / event name= drawOpened code= D2OP / event name= lightOn code= L1ON / event name= doorOpened code= D1OP / event name= panelClosed code= PNCL / command name= unlockPanel code= PNUL / command name= lockPanel code= PNLK / command name= lockDoor code= D1LK / command name= unlockDoor code= D1UL / state name= idle transition event= doorClosed target= active / action command= unlockDoor / action command= lockPanel / /state state name= active transition event= drawOpened target= waitingForLight / transition event= lightOn target= waitingForDraw / /state state name= waitingForLight transition event= lightOn target= unlockedPanel / /state state name= waitingForDraw transition event= drawOpened target= unlockedPanel / /state state name= unlockedPanel action command= unlockPanel / action command= lockDoor / transition event= panelClosed target= idle / /state resetEvent name = doorOpened / /stateMachine This style of representation should look familiar to most readers, I ve expressed it as an XML file. There are several advantages to doing it this way. One obvious reason is that now we don t have to compile a separate java program for each controller we put into the field - instead we can just compile the state machine components plus an appropritate parser into a common jar, and ship the xml file to be read when the machine starts up. Any changes to the behavior of the controller can be done without having to distribute a new jar. (We do, of course, pay for this in that any mistakes in the syntax of the configuration can only be detected at run time.) A second advantage is in the expressiveness of the file itself. We no longer need to worry about the details of making the various connections through variables. Instead we have a more declarative approach that in many ways reads much more clearly. We re also limited in that we can only express configuration in this file - limitations like this often are helpful because they can reduce the chances for people making mistakes in the component assembly code. These advantages are why so many frameworks in Java and C# are configured with XML configuration files. These days it sometimes feels that you re doing more programming with XML than you are with main programming language. Here s another version of the configuration code. events doorClosed D1CL drawOpened D2OP lightOn L1ON doorOpened D1OP panelClosed PNCL end resetEvents doorOpened end commands unlockPanel PNUL lockPanel PNLK lockDoor D1LK unlockDoor D1UL end state idle actions {unlockDoor lockPanel} doorClosed = active end state active drawOpened = waitingForLight lightOn = waitingForDraw end state waitingForLight lightOn = unlockedPanel end state waitingForDraw drawOpened = unlockedPanel end state unlockedPanel actions {unlockPanel lockDoor} panelClosed = idle end This is code, although not in a syntax that s familiar to you. In fact it s a custom syntax that I made up for this example. I think it s a syntax that s easier to write, and above all easier to read, than the XML syntax. It s terser and avoids a lot of the quoting and noise characters that the XML suffers from. You probably wouldn t have done it exactly the same way, but the point is that you can construct whatever syntax you and your team prefers. You can still load it in at runtime (like the XML) but you don t have to (as you don t with the XML) if you want it at compile time. This language is a Domain Specific Language, and shares many of the characteristics of DSLs. Firstly it s suitable only for a very narrow purpose - it can t do anything other than configure this particular kind of state machine. As a result the DSL is very simple - there s no facility for control structures or anything else. It s not even Turing complete. You couldn t write a whole application in this language - all you can do is describe one small aspect of an application. As a result the DSL has to be combined with other languages to get anything done. But the simplicity of the DSL means it s easy to edit and process. Now look again at the XML representation. Is this a DSL? I would argue that it is. It s wrapped in an XML carrier syntax - but it s still a DSL. This example thus raises a design issue - is it better to have custom syntax for a DSL or an XML syntax? The XML syntax can be easier to parse since people are so familiar with parsing XML. (As it happened for this example it took me the about the same amount of time to write the parser for the custom syntax as it did for the XML.) I d contend that the custom syntax is much easier to read, at least in this case. But however you view this choice the core trade-offs around DSLs are the same. Indeed you can argue that most XML configuration files are essentially DSLs. Let s go back a step further, back to the configuration code in Java I showed you earlier - is that a DSL? While you re thinking about that question look at this code. Does this look like a DSL for this problem? event doorClosed, D1CL event drawOpened, D2OP event lightOn, L1ON event doorOpened, D1OP event panelClosed, PNCL command unlockPanel, PNUL command lockPanel, PNLK command lockDoor, D1LK command unlockDoor, D1UL resetEvents doorOpened state idle do actions unlockDoor, lockPanel transitions doorClosed = active end state active do transitions drawOpened = waitingForLight, lightOn = waitingForDraw end state waitingForLight do transitions lightOn = unlockedPanel end state waitingForDraw do transitions drawOpened = unlockedPanel end state unlockedPanel do actions unlockPanel, lockDoor transitions panelClosed = idle end It s a bit noisier than the custom language earlier, but still pretty clear. Readers who have similar language likings to me will probably know that it s Ruby. Ruby gives me a lot of syntactic options that makes for more readable code, so I can make it look very similar to the custom language. Ruby developers would consider this code to be a DSL. I use a subset of the capabilities of Ruby and capture same ideas as our XML and custom syntax. Essentially I m embedding the DSL into ruby, using a subset of ruby as my syntax. To an extent this is more a matter of attitude than of anything else. I m choosing to look at the Ruby code through DSL glasses. But it s a point of view with a long tradition - Lisp programmers often think of creating DSLs inside Lisp. This brings me to pointing out that there are two kinds of textual DSLs which I call external and internal DSLs. AnExternal DSLis a domain specific language represented in a separate language to the main programming language it s working with. This language may be a custom syntax, or it may follow the syntax of another representation (like XML). AnInternal DSLis DSL expressed within the syntax of a general purpose language. It s a stylized use of that language for a domain specific purpose. You may also hear the termembedded DSLas a synonym for internal DSL. Although it is fairly widely used, I avoid this term because you also hear embedded language applied to scripting languages embedded within applications such as VBA in Excel or Scheme in the Gimp. So I use internal DSL to avoid confusion. Now think again about the original java configuration code - is this a DSL? I would argue that it isn t. That code feels like stitching together with an API, while the ruby code above has more the feel of a declarative language. Does this mean you can t do an internal DSL in Java? How about this? public class BasicStateMachine extends StateMachineBuilder { Events doorClosed, drawOpened, lightOn, panelClosed; Commands unlockPanel, lockPanel, lockDoor, unlockDoor; States idle, active, waitingForLight, waitingForDraw, unlockedPanel; ResetEvents doorOpened; protected void defineStateMachine() { doorClosed. code( D1CL ); drawOpened. code( D2OP ); lightOn. code( L1ON ); panelClosed.code( PNCL ); doorOpened. code( D1OP ); unlockPanel.code( PNUL ); lockPanel. code( PNLK ); lockDoor. code( D1LK ); unlockDoor. code( D1UL ); idle .actions(unlockDoor, lockPanel) .transition(doorClosed).to(active) ; active .transition(drawOpened).to(waitingForLight) .transition(lightOn). to(waitingForDraw) ; waitingForLight .transition(lightOn).to(unlockedPanel) ; waitingForDraw .transition(drawOpened).to(unlockedPanel) ; unlockedPanel .actions(unlockPanel, lockDoor) .transition(panelClosed).to(idle) ; } } It s formatted oddly, and uses some unusual programming conventions, but it is valid Java. It s java written in what is these days called a Fluent Interface style. AFluent Interfaceis an API that s designed to read like an internal DSL. This I would call a DSL - although it s more messy than the ruby DSL it still has that declarative flow that a DSL needs. What makes a fluent interface different to a normal API? This is a tough question that I ll spend more time onlater), but it comes down to a rather fuzzy notion of a language-like flow. Given this distinction it s useful to have a name for a non-fluent API - I ll use the termcommand-query API. Languages and Model There s an important inter-relationship here between the various DSLs and the underlying state-machine model. To implement each of these languages I wrote code that translated from expressions in the DSL into calls on the command-query interface of the model. So while I was parsing the custom syntax version and came across commands unlockPanel PNUL I would create a new command object (new Command( unlockPanel , PNUL )) and keep it to one side (in aSymbol Table) so that when I sawactions {unlockPanelI could add it to the appropriate state (usingaddAction). As a result each DSL I ve shown you created the same configuration of objects in the model. The model, as I discussed earlier, is the engine that provides the behavior of the state-machine. So once we have a populated model, we have a running program whose behavior is encoded in the inter-relationships between the objects in that model. This style is often called an Active Object Model, because in order to understand the behavior of the state machine you can t just look at the code, you also have to look at the way object instances are wired together. Of course this is always true to some extent, any program gives different results with different data, but there is a sense of a greater difference here as the presence of the state objects alters the behavior of the system to a significantly greater degree. When people discuss a programming language you often hear them talk about syntax and semantics. The syntax captures the legal expressions of the program, what in the custom syntax DSL is captured by the grammar. The semantics of a program is what it means, that is what it does when it executes. In this case it is the model that defines those semantics - which is why I will refer to it as aSemantic Model. In this example theSemantic Modelis an object model. ASemantic Modelcan also take other forms. It can be a pure data structure with all behavior in separate functions. I would still refer to it as an active model, because the data structure defines the program s behavior. Looking at it from this point of view, the DSL merely acts as a mechanism for expressing how the model is configured. I often refer to a DSL as a thin facade over a framework. Much of the benefits of using this approach comes from the model rather than the DSLs. The fact that I can easily configure a new state machine for a customer is a property of the model, not the DSL. The fact that I can make a change to a controller at run-time, without compiling, is a feature of the model, not the DSL. The fact I m reusing code across multiple installations of controllers is a property of the model, not the DSL. A model provides many benefits without any DSLs present. As a result we use them all the time. We use libraries and frameworks to wisely avoid work. In our own software we construct our own models, building up abstractions that allow us to program faster. Good models, whether published as libraries and frameworks or just serving our own code, can work just fine without any DSL in sight. But DSLs can enhance the the capabilities of a model. The right DSL makes it easier to understand what a particular state machine does. Some DSLs allow you to configure the model at run time. DSLs are thus a useful adjunct to some models. In discussing this example I described a circumstance where the model was built first, and then I layered a DSL over the model to help manipulate it. I described it that way becuase I think that s an easy way to understand how DSLs fit into software development. Although the model-first case is a common one, it isn t the only one. In a different scenario you talk with the domain experts and posit that a state machine approach is something they understand. You then work with the domain experts to create a DSL that they can understand. In this case you build the DSL and model simultaneously. Using Code-Generation In my discussion so far, I process the DSL by populating theSemantic Modeland then execute theSemantic Modelto provide the behavior that I want from the controller. This approach is what s known in language circles as interpretation. When weinterpretsome text, we parse it and immediately produce the result that we want from the program. (Interpret is a tricky word in software circles, since it carries all sorts of connotations for people, however I ll use it strictly to mean this form of immediate execution.) In the language world, the alternative to interpretation is compilation. Withcompilation, we parse some program text and produce an intermediate output, which is then separately processed to provide the behavior we desire. In the context of DSLs the compilation approach is usually referred to ascode-generation. In this case this might mean generating some java code to represent the particular behavior of Miss Grant s controller. Code generation is often awkward in that it often pushes you to an extra compilation. To build your program you have to first compile the state framework and the parser, then run the parser to generate the source code for Miss Grant s controller, then compile that generated code. This makes your build process much more complicated. However an advantage of code generation is that there s no reason why you have to generate code in same programming language that you use for the parser. In this case you can avoid the second compilation step by generating code for a dynamic language such as javascript or jruby. Code generation is also useful when you want to use DSLs with a language platform that doesn t have the tools for DSL support. I ve come across recent projects that generate code for MathCAD, SQL, and COBOL. Many writings on DSLs focus on code-generation, even to the point of making code-generation the primary aim of the exercise. As a result you can find articles and books extolling the virtues of code-generation. In my view, however, code-generation is merely an implementation mechanism, one that isn t actually needed in most cases. Certainly there are plenty of times when you must use code-generation, but there are even more plenty of times when you don t need it. Using code-generation is one case where many people don t use aSemantic Model. In this case you parse the input text and directly produce the generated code. Although this is a common way of working with code-generated DSLs, it isn t one I reccommend for any but the very simplest cases. Using aSemantic Modelallows me to separate the parsing, the execution semantics, and the code generation into separate problems. This separation makes the whole exercise a lot simpler. It also allows me to change my mind. I can change my DSL from an internal to an external DSL (say) without altering my code-generation routines. Similarly I can easily generate multiple outputs without complicating my parse. I can also use both an interpreted model and code generation off the sameSemantic Model. As a result for almost all of this book, I m going to assume aSemantic Modelis present and the centre of the DSL effort. Using Language Workbenches The two styles of DSL I ve shown so far (internal and external) are the traditional ways of thinking about DSLs. They may not be as widely understood and used as they should be, but they have a long history and moderately wide usage. As a result the rest of this book concentrates on getting you started with these approaches using tools that are mature and easy to obtain. But there is a whole new category of tools on the horizon that could change the game of DSLs significantly tools I call Language Workbenches. ALanguage Workbenchis tool designed to help people create new DSLs, together with high quality tooling required to use those DSLs effectively. One of the big disadvantages of using an external DSL is that you re stuck with relatively limited tooling. Setting up syntax highlighting with a text editor is about as far as most people go. While you can argue that the simplicity of a DSL and the small size of the scripts means that may be enough, there s also an argument for the kind of sophisticated tooling that modern post-IntelliJ IDEs support. Language Workbenches make it easy not just to define a parser, but also to define a custom editing environment for that language. All of this is valuable, but the truly interesting aspect of language workbenches is that they allow a DSL designer to go beyond the the traditional text-based source editing, to different forms of language. The most obvious example of this is support for diagrammatic languages, which would allow me to specify the secret panel state machine directly with a state transition diagram. Figure 3 The secret panel state machine displayed in the MetaEdit language workbench.(source MetaCase) Not just does a tool like this allow you to have diagrammtic languages, it also allows you to look at a DSL script from multiple perspectives. In Figure3there is a diagram, but also lists of states and events, and a table to enter the event codes (which could be ommitted from the diagram if there s too much clutter there). This kind of multi-pane visual editing environment has been around for a while in lots of tools, but it s been a lot of effort to build something like this for yourself. One promise of language workbenches is that they make it quite easy to do this, certainly I was easily able to put together a similar example to Figure3quite quickly on my first play with the MetaEdit tool. The tools allows me to define theSemantic Modelfor state machines, define the graphical and tabular editors in Figure3and write a code generator from theSemantic Model. However, while such tools certainly look good, many developers are naturally suspicious of such doodleware tools. There are some very pragmatic reasons why a textual source representation makes sense. As a result other tools head in that direction, providing post-IntelliJ style capabilities such as syntax-directed editing, symbol completion and the like to textual languages. My own suspicion here is that if language workbenches really take off, the languages they ll produce aren t anything like what we consider to be a programming language. One of the common benefits of tools like this is that they allow non-programmers to program. I often sniff at that notion by pointing out that this was the original intent of COBOL. Yet I must also acknowledge a programming environment that has been extremely successful in providing programming tools to non-programmers who program without thinking of themselves of programming - spreadsheets. In programming language terms spreadsheets are based on a quite unusual computational model. Their appeal comes from a very deep integration of the notions of language and tool. Thus it s no surprise that Charles Simonyi combines both a history of development of these kinds of user tools with a long history of developing ideas in language workbenches. As a result I think that language workbenches have a remarkable potential. If they fulfill this they could entirely change the face of software development. This potential, however profound, is still somewhat in the future. It s still early days for language workbenches with new approaches appearing regularly and older tools still subject to deep evolution. As a result I don t have that much to say about them here, as I think they will change quite dramatically during the hoped-for lifetime of this book. But I do have a chapter on them at the end, as I think they are well worth keeping an eye on. Visualization One the great advantages of using a Language Workbench is that this enables you to a wider range of representations of the DSL, in particular graphical representations. However even with a textual DSL you can obtain a diagrammatic representation. Indeed we saw this very early on in this chapter. When looking at Figure1it might have struck you that the diagram was not as neatly drawn as I usually do. The reason for this is that I didn t draw the diagram, I generated it automatically from theSemantic Modelof Miss Grant s controller. Not just do my state machine classes execute, they also are able to render themselves use the dot language. The dot langauge is part of the GraphViz package, which is an open-source tool that allows you to describe mathematical graph structures (nodes and edges) and then automatically plot them. It figures out how to lay out the graph, you just tell it what the nodes and edges are, what shapes to use, and some other hints. Using a tool like GraphViz is extremely helpful for many kinds of DSLs because it gives another representation. Thisvisualizationrepresentation is similar to the DSL itself in that it allows a human to understand the model. The diference between a visualization and the source is that it isn t editable - however it can provide options that are too hard in an editable form, such as a diagram like this. In the terms of a language workbench you can think of a visualization as a read-only projection. It s something that can be less important for graphical language workbenches, since you use a diagram anyway, but it s still sometimes a handy technique. Visualizations don t have to be graphical. I often use a simple textual visualization to help me debug while I m writing a parser. I ve seen people generate visualizations in Excel to help communicate with domain experts. The point is that once you have done the hard work of creating a component framework like this, adding visualizations is really easy. You ll note here that the visualizations are produced from the framework, not the DSL, so you can do this even if you aren t using a DSL to populate the framework. Indeed the techniques in this book can be used for creating visualizations above and beyond DSL usage. A partial parser for a general purpose language can be used to visualize useful aspects of a general purpose program. Any interesting data strucutre can be visualized in interesting ways. Significant Revisions 06 Aug 07 First Draft 09 Apr 08 Split example from general issues
https://w.atwiki.jp/warband/pages/420.html
p_zendar|Zendar p_town_1|Wien, Oesterreich p_town_2|Pressburg p_town_3|Königsberg p_town_4|Nantes p_town_5|Berlin, Preußen p_town_6|Paris, France p_town_7|Bordeaux p_town_8|London, England p_town_9|Cardiff p_town_10|Frankfurt, Aschaffenburg p_town_11|Edinburgh p_town_12|Prag p_town_13|Dublin p_town_14|München p_town_15|Stettin p_town_16|Toulouse p_town_17|Stuttgart p_town_18|Ratisbon p_town_19|Sankt-Peterburg, Rossiya p_town_20|Moskva p_town_21|Kiev p_town_22|Minsk p_town_23|Warszawa, Polska p_town_24|Napoli, Napoli p_town_25|L'Aquila p_town_26|Matera p_town_27|Milano, Italia p_town_28|Amsterdam, Holland p_town_29|Orléans p_town_30|Hanovre p_town_31|Rome p_town_32|Liège p_town_33|Arnhem p_town_34|Groningen p_town_35|Sheffield p_town_36|Wilton p_town_37|Inveraray p_town_38|Gießen p_town_39|Göttingen p_town_40|Salzburg p_town_41|Laibach p_town_42|Venezia p_town_43|Konitz p_town_44|Poznan p_town_45|Torun p_town_46|Ostrog p_town_47|Kherson p_town_48|Pskov p_town_49|Grodno p_town_50|Lublin p_town_51|Luxembourg p_castle_1|Military Depot, France p_castle_2|Military Depot, England p_castle_3|Military Depot, Rhineland p_castle_4|Military Depot, Austria p_castle_5|Military Depot, Prussia p_castle_6|Military Depot, Russia p_castle_7|Military Depot, Poland p_castle_8|Military Depot, Naples p_castle_9|Military Depot, Italy p_castle_10|Military Depot, Holland p_village_1|Compiegne p_village_2|Le Mans p_village_3|Brest p_village_4|Chartres p_village_5|Buda Pest p_village_6|Sarrebourg p_village_7|Bayonne p_village_8|Austerlitz p_village_9|Potsdam p_village_10|Wagram p_village_11|Landshut p_village_12|Stargard p_village_13|Calais p_village_14|Nottingham p_village_15|Narbonne p_village_16|Dover p_village_17|Liverpool p_village_18|Belfast p_village_19|Carlisle p_village_20|Portsmouth p_village_21|Canterbury p_village_22|Dundee p_village_23|Eylau p_village_24|Friedland p_village_25|Bozen p_village_26|Allenstein p_village_27|Köslin p_village_28|Aschaffenburg p_village_29|Czernowitz p_village_30|Neusatz p_village_31|Linz p_village_32|Marseilles p_village_33|La Rochelle p_village_34|Dijon p_village_35|Klagenfurt p_village_36|Aspern p_village_37|Meppen p_village_38|Napoleonville p_village_39|Nice p_village_40|Reichenbach p_village_41|Düsseldorf p_village_42|Wiesbaden p_village_43|Braunschweig p_village_44|Leipzig p_village_45|Görlitz p_village_46|Sagan p_village_47|Landsberg p_village_48|Vannes p_village_49|Galway p_village_50|Cork p_village_51|Brünn p_village_52|Ulm p_village_53|Treves p_village_54|Cherbourg p_village_55|Bayeux p_village_56|Hermannstadt p_village_57|Arras p_village_58|Caernarvon p_village_59|Puck p_village_60|Poitiers p_village_61|Fünfkirchen p_village_62|Wrexham p_village_63|Troyes p_village_64|Muncheberg p_village_65|Carcassonne p_village_66|Eckington p_village_67|Norwich p_village_68|Pritzwalk p_village_69|Tarnopol p_village_70|Soldin p_village_71|Rheims p_village_72|Frankfurt p_village_73|Kosel p_village_74|Birmingham p_village_75|Jena p_village_76|Münster p_village_77|Szegedin p_village_78|Braunsberg p_village_79|Polnisch Krone p_village_80|Brieg p_village_81|Sankt Polten p_village_82|Anvers p_village_83|Split p_village_84|Gransee p_village_85|Aberdeen p_village_86|Ullapool p_village_87|Carmarthen p_village_88|Heidelberg p_village_89|High Wycombe p_village_90|Eberswalde p_village_91|Borodino p_village_92|Narva p_village_93|Dneprova p_village_94|Glebokie p_village_95|Vladimir p_village_96|Rakaw p_village_97|Lida p_village_98|Mitau p_village_99|Tiraspol p_village_100|Staraya Ladoga p_village_101|Valdai p_village_102|Borovsk p_village_103|Vologda p_village_104|Pinsk p_village_105|Elisabethgrad p_village_106|Taganrog p_village_107|Bogatye p_village_108|Roslavl p_village_109|Ostrov p_village_110|Yaroslavl p_village_111|Praga p_village_112|Rawa p_village_113|Gora p_village_114|Salerno p_village_115|Cassino p_village_116|Benevento p_village_117|Teramo p_village_118|Trivento p_village_119|Foggia p_village_120|Venosa p_village_121|Brindisi p_village_122|Rivello p_village_123|Pavia p_village_124|Mantua p_village_125|Brescia p_village_126|Leiden p_village_127|Zwolle p_village_128|Amersfoort p_village_129|Auxerre p_village_130|Bouges p_village_131|Caen p_village_132|Celle p_village_133|Weblen p_village_134|Ludersbourg p_village_135|Sienne p_village_136|Ferentino p_village_137|Orte p_village_138|Schœneck p_village_139|Namur p_village_140|Enghien p_village_141|Zutphen p_village_142|Steensel p_village_143|Venloon p_village_144|Eernewoude p_village_145|Emmen p_village_146|Zant p_village_147|Selby p_village_148|Durham p_village_149|Keighley p_village_150|Tavistock p_village_151|Reading p_village_152|Hartford p_village_153|New Galloway p_village_154|Gairloch p_village_155|Doune p_village_156|Blankenberg p_village_157|Eisenach p_village_158|Eisfeld p_village_159|Wipperfürth p_village_160|Abenberg p_village_161|Magdeburg p_village_162|Przibram p_village_163|Weitra p_village_164|Pilgram p_village_165|Marburg p_village_166|Inselburg p_village_167|Agram p_village_168|Aviano p_village_169|Mesola p_village_170|Lonego p_village_171|Mirachow p_village_172|Labes p_village_173|Pasewalk p_village_174|Gniezno p_village_175|Leczyca p_village_176|Koscian p_village_177|Plock p_village_178|Chelmno p_village_179|Lomza p_village_180|Dasina p_village_181|Uman p_village_182|Rahachow p_village_183|Vyska p_village_184|Olviopol p_village_185|Vinnytsya p_village_186|Tver p_village_187|Pernau p_village_188|Vroclav p_village_189|Szaly p_village_190|Seda p_village_191|Aloja p_village_192|Siedlce p_village_193|Radom p_village_194|Sandomir p_village_195|Mortain p_village_196|Roanne p_village_197|Valence p_salt_mine|Salt Mine p_four_ways_inn|Four Ways Inn p_test_scene|test scene p_battlefields|battlefields p_dhorak_keep|Dhorak Keep p_training_ground|Training Ground p_training_ground_1|Training Field p_training_ground_2|Training Field p_training_ground_3|Training Field p_training_ground_4|Training Field p_training_ground_5|Training Field p_steppe_bandit_spawn_point|the steppes p_taiga_bandit_spawn_point|the tundra p_forest_bandit_spawn_point|the forests p_mountain_bandit_spawn_point|the highlands p_sea_raider_spawn_point_1|the coast p_sea_raider_spawn_point_2|the coast p_desert_bandit_spawn_point|the deserts
https://w.atwiki.jp/xboxonescore/pages/704.html
Plants vs. Zombies Garden Warfare 2 項目数：63（51+12） 総ポイント：1250（1000+250） 難易度：☆☆☆☆☆ Trials of Gnomus ～250：☆☆☆☆☆ 製品情報： 配信日：2016年2月23日 DL費用：¥1,944 (税込) ジャンル：シューティング ※日本語未対応 Time to Go Outside Promote a single character 5 times.一つのキャラクターを5回昇進させた。 100 Star Crazy Spend your first star.スターを初めて消費した。 25 Rinsed Em Vanquish 5000 Zombies.ゾンビ達を5000体バンキッシュした。 25 Gramma Z Says… Vanquish 5000 Plants.プラント達を5000体バンキッシュした。 25 Insanity Complete an Ops game on CRRRRRAAAZY Difficulty.Ops gameを難易度CRRRRRAAAZYでクリアする。 50 Catching Waves Complete 100 waves in Ops.Opsで100waveクリアする。 50 Not the Boss of Me Defeat 3 Super Boss Waves in Ops.OpsでSuper Boss waveを3回クリアする。 25 It s My Island Reach the boss wave using the Flag of Power in the Backyard Battleground.the Backyard BattlegroundのFlag of powerでBoss waveに到達する。 50 Really Epic! Complete 10 Epic Quests.Epicクエストを10個クリアする。 10 The Boss is Watching Max out your XP Multiplier on the quest board.クエストボードのXP倍率を最大にする。 25 Stomp the Yard Vanquish 50 Plants with the Z-Mech s Robo Stomp.Z-Mech s Robo Stompでプラント達を50体バンキッシュする。 10 Just Peachy! Stun 50 Z-Mechs using Citron s EMPeach.Citron s EMPeachでZ-Mechs類を50体スタンさせる。 10 Simply Super As Super Brainz, vanquish 25 Plants with Heroic Fists, and 25 Plants with the Heroic Beam.Super BrainzのHeroic Fistsで25体、the Spyglass Shotで25体のプラント達をバンキッシュする。 10 My Place or Yours Vanquish 25 Plants with the Scurvy Scattershot, and 25 Plants with the Spyglass Shot.piratesのthe Scurvy Scattershotで25体、the Heroic Beamで25体のプラント達をバンキッシュする。 10 Specialist Promote a character for the first time.初めてキャラクターを昇進させる。 10 Hawkguy Earn a S-Rank in the Crazy Target Range.the Crazy Targets RangeでSランクを獲得する。 10 Prance vs Samba Gesture immediately after vanquishing a player.プレイヤーをバンキッシュした後すぐにジェスチャーをする。 5 Playdate Visit a friend s Backyard Battleground, or have a friend visit your Backyard Battleground.フレンドのBackyard Battlegroundを訪れる。あるいは自分のBackyard Battlegroundにフレンドが訪れる。 5 Who Can You Trust? Vanquish a friend in their Backyard Battleground.自分かフレンドのBackyard Battlegroundでフレンドをバンキッシュする。 5 Always IMProvising Apply a weapon skin to a Zombie s weapon.ゾンビたちの武器にスキンを適用する。 10 Hero to Zero Vanquish an opponent using a Potted Plant or Zombot TurretPotted PlantまたはZombot Turretで敵をバンキッシュする。 10 Skinchanger In solo ops, swap to another character.一人プレイのOpsで、他のキャラクターに替わる。 10 VIPs Only! Play a private match with your own custom rules.自分でルールをカスタマイズしたプライベートマッチで遊ぶ。 5 You ve Goat to Be Kidding Me! As Rose, Goatify 100 Zombies.Roseで100体のゾンビ達を羊にする。 10 Aww Shucks! As Kernel Corn, vanquish 25 Zombies with the Shuck Shot.Cornでthe Shuck Shotを使用して25体のゾンビ達をバンキッシュする。 10 Corn Identity Enter the Zombie Stats room as a Plant.プラントでゾンビのstats roomに入る。 10 Gnomore! Find all hidden Garden Gnomes.隠されたGarden Gnomeをすべて発見する。 25 Gnome Man s Land Enter the Chamber of Gnomes.the Chamber of Gnomesに入る。 25 My Favourite Z-Mech on the Citadel As a Plant, vanquish the Z7 Imp.プラントで、Z7 Impをバンキッシュする。 5 Goat Any Last Words? As a Goat, vanquish a Plant.羊でプラントをバンキッシュする。 10 Goatmeal As the Chomper, swallow a Goat.the Chomperで羊を飲み込む。 10 Behind Enemy Vines Enter the Plant Stats room as a Zombie.ゾンビでプラントのstats roomに入る。 10 Just Sprouted Complete Boom the Tombs Boom Tombs を完了する。 5 On the Cob Complete Zero Bark Thirty Zero Bark Thirty を完了する。 5 Her Majesty Complete Well That Escalated Quickly Well That Escalated Quickly を完了する。 10 Mango Tango Complete Showdown Showdown を完了する。 10 Curseproof Complete Pirate s Curse Captain Smasher s Curse を完了する。 10 Yuck! Complete Yuck! . Yuck! を完了する。 10 The Bean Situation Complete The Bean Situation . The Bean Situation を完了する。 10 Got Golden Complete Gold Rush . Gold Rush を完了する。 10 Warp Tour Complete Steve-cation . Steve-cation を完了する。 10 What a Trip Complete Goin for a Trip Strong Coffee を完了する。 10 What s the Catch? Train with the Mysterious Fish.謎の魚を養成する。 25 Lawn Care Customize your Backyard with an Epic Item.Epic Itemを使って、自分のBackyardをカスタマイズする。 25 West Indian Lilac Enter Infinity as a Plant.プラントでInfinityに入る。 25 String Theory Enter Infinity as a Zombie.ゾンビでInfinityに入る。 25 King of Summer Defeat Yellow Gnome KingYellow Gnome Kingを倒す。 25 King of Winter Defeat Blue Gnome KingBlue Gnome Kingを倒す。 25 King of Spring Defeat Green Gnome KingGreen Gnome Kingを倒す。 25 King of Autumn Defeat Red Gnome KingRed Gnome Kingを倒す。 25 RGBY Vanquish Gnomus, the Gnome King!ノームの王Gnomusをバンキッシュ！ 100 Title update Trials of Gnomus：250 It s Not a Door...it s a Portal! Complete 3 Mystery Portal MatchesMystery Portal Matcheを3回完了する。 10 The Secret of Secrets Discover the Secret Area…What can it be?秘密の場所を発見…何だこれは！？ 50 This is Craaazy! Enter the Mystery Portal and Complete a Super Mix Event!the Mystery Portalに入り、Super Mix Eventを完了する。 5 Somewhere Over the Rainbow Collect 25 Rainbow Stars from the Mystery Portalthe Mystery PortalでRainbow Starを25個集める。 10 Alright Meow Enter the Mystery Portal and Complete a Full Game of Cats vs Dinos as a Catthe Mystery Portalに入り、Cats vs Dinosをcatで完了する。 5 Open the Door Get on the Floor Enter the Mystery Portal and Complete a Full Game of Cats vs Dinos as a Dinothe Mystery Portalに入り、Cats vs Dinosをdinoで完了する。 5 Boss Battle Enter the Mystery Portal and Defeat a Boss Hunt on Normal Difficultythe Mystery Portalに入り、難易度NormalでBoss Huntに成功する。 5 Boss Battle Specialist Enter the Mystery Portal and Defeat a Boss Hunt on Hard Difficultythe Mystery Portalに入り、難易度HardでBoss Huntに成功する。 10 Boss Battle Boss Enter the Mystery Portal and Defeat a Boss Hunt on Craaazy Difficultythe Mystery Portalに入り、難易度CraaazyでBoss Huntに成功する。 50 More Secrets? New Faces from Craazy Placesクレイジーな場所からのニューフェイスです！ 50 Team Player Meet the Contribution Requirement for 3 Community ChallengesCommunity Challengesで3回貢献必要条件を満たす。 25 Together we Win Open 5 Community Challenge Reward Chests.Community Challengeの報酬の宝箱を5つ開ける。 25 +日本語訳のみ Time to Go Outside 一つのキャラクターを5回昇進させた。 100 Star Crazy スターを初めて消費した。 25 Rinsed Em ゾンビ達を5000体バンキッシュした。 25 Gramma Z Says… プラント達を5000体バンキッシュした。 25 Insanity Ops gameを難易度CRRRRRAAAZYでクリアする。 50 Catching Waves Opsで100waveクリアする。 50 Not the Boss of Me OpsでSuper Boss waveを3回クリアする。 25 It s My Island the Backyard BattlegroundのFlag of powerでBoss waveに到達する。 50 Really Epic! Epicクエストを10個クリアする。 10 The Boss is Watching クエストボードのXP倍率を最大にする。 25 Stomp the Yard Z-Mech s Robo Stompでプラント達を50体バンキッシュする。 10 Just Peachy! Citron s EMPeachでZ-Mechs類を50体スタンさせる。 10 Simply Super Super BrainzのHeroic Fistsで25体、the Spyglass Shotで25体のプラント達をバンキッシュする。 10 My Place or Yours piratesのthe Scurvy Scattershotで25体、the Heroic Beamで25体のプラント達をバンキッシュする。 10 Specialist 初めてキャラクターを昇進させる。 10 Hawkguy the Crazy Targets RangeでSランクを獲得する。 10 Prance vs Samba プレイヤーをバンキッシュした後すぐにジェスチャーをする。 5 Playdate フレンドのBackyard Battlegroundを訪れる。あるいは自分のBackyard Battlegroundにフレンドが訪れる。 5 Who Can You Trust? 自分かフレンドのBackyard Battlegroundでフレンドをバンキッシュする。 5 Always IMProvising ゾンビたちの武器にスキンを適用する。 10 Hero to Zero Potted PlantまたはZombot Turretで敵をバンキッシュする。 10 Skinchanger 一人プレイのOpsで、他のキャラクターに替わる。 10 VIPs Only! 自分でルールをカスタマイズしたプライベートマッチで遊ぶ。 5 You ve Goat to Be Kidding Me! Roseで100体のゾンビ達を羊にする。 10 Aww Shucks! Cornでthe Shuck Shotを使用して25体のゾンビ達をバンキッシュする。 10 Corn Identity プラントでゾンビのstats roomに入る。 10 Gnomore! 隠されたGarden Gnomeをすべて発見する。 25 Gnome Man s Land the Chamber of Gnomesに入る。 25 My Favourite Z-Mech on the Citadel プラントで、Z7 Impをバンキッシュする。 5 Goat Any Last Words? 羊でプラントをバンキッシュする。 10 Goatmeal the Chomperで羊を飲み込む。 10 Behind Enemy Vines ゾンビでプラントのstats roomに入る。 10 Just Sprouted Boom Tombs を完了する。 5 On the Cob Zero Bark Thirty を完了する。 5 Her Majesty Well That Escalated Quickly を完了する。 10 Mango Tango Showdown を完了する。 10 Curseproof Captain Smasher s Curse を完了する。 10 Yuck! Yuck! を完了する。 10 The Bean Situation The Bean Situation を完了する。 10 Got Golden Gold Rush を完了する。 10 Warp Tour Steve-cation を完了する。 10 What a Trip Strong Coffee を完了する。 10 What s the Catch? 謎の魚を養成する。 25 Lawn Care Epic Itemを使って、自分のBackyardをカスタマイズする。 25 West Indian Lilac プラントでInfinityに入る。 25 String Theory ゾンビでInfinityに入る。 25 King of Summer Yellow Gnome Kingを倒す。 25 King of Winter Blue Gnome Kingを倒す。 25 King of Spring Green Gnome Kingを倒す。 25 King of Autumn Red Gnome Kingを倒す。 25 RGBY ノームの王Gnomusをバンキッシュ！ 100 Title update Trials of Gnomus：250 It s Not a Door...it s a Portal! Mystery Portal Matcheを3回完了する。 10 The Secret of Secrets 秘密の場所を発見…何だこれは！？ 50 This is Craaazy! the Mystery Portalに入り、Super Mix Eventを完了する。 5 Somewhere Over the Rainbow the Mystery PortalでRainbow Starを25個集める。 10 Alright Meow the Mystery Portalに入り、Cats vs Dinosをcatで完了する。 5 Open the Door Get on the Floor the Mystery Portalに入り、Cats vs Dinosをdinoで完了する。 5 Boss Battle the Mystery Portalに入り、難易度NormalでBoss Huntに成功する。 5 Boss Battle Specialist the Mystery Portalに入り、難易度HardでBoss Huntに成功する。 10 Boss Battle Boss the Mystery Portalに入り、難易度CraaazyでBoss Huntに成功する。 50 More Secrets? クレイジーな場所からのニューフェイスです！ 50 Team Player Community Challengesで3回貢献必要条件を満たす。 25 Together we Win Community Challengeの報酬の宝箱を5つ開ける。 25
https://w.atwiki.jp/devlin/pages/6.html
アーカイブ一覧 ベルクのスタッフ BERG店長・井野朋也に聞く39の質問 （2008年5月24日 06 54の魚拓） BERG副店長・迫川尚子に聞く39の質問 (2008年5月24日 06 58 の魚拓) ベルクの職人さん コーヒー職人・久野富雄さんに聞く39の質問 (2008年5月24日 19 40 の魚拓) ソーセージ職人・河野仲友さんに聞く39の質問 (2008年5月24日 19 45 の魚拓) パン職人・高橋康弘さんに聞く39の質問 (2008年5月24日 19 46 の魚拓) ベルクのこだわり人 自然卵のこだわり・小林達幸さん (2008年5月24日 19 51 の魚拓) ワインのこだわり・内藤邦夫さん (2008年5月24日 19 53 の魚拓) 日本酒のこだわり・高原廣志さん (2008年5月24日 19 54 の魚拓) ベルク退店問題 毎日新聞 食べたい：今夜も赤ちょうちん 新宿駅東口 ７０年代の余熱、消さないで＝鈴木琢磨 （2008年6月3日 東京夕刊。2008年6月3日 22 07 の魚拓） おかしいぞ！JR商法～「ベルク」立ち退き問題でJRウォッチが申入れ (2008年5月24日 20 03 の魚拓＠レイバーネット 5月20日) 2008年2月28日『東京新聞』夕刊「立ち退き騒動 ファン“注文”殺到」 (2008年2月28日夕刊）＠LOVE! BERG!、2008年5月26日 23 26 の魚拓) 新宿駅最後の小さなお店 朝日新聞 新宿駅最後の小さなお店ベルク（掲載]2008年10月5日[評者]清野由美（ジャーナリスト）2008年10月14日 14 33の魚拓） トラックバックURL http //www9.atwiki.jp/devlin/tb/6.html
https://w.atwiki.jp/niconicomugen/pages/9766.html
性別：男の子 身長：160cm 体重：72kg 好きな食べ物：チョコマシュマロ、アポロ（苺の形をした某菓子） グレイティなどを手掛けたGreatyfan2005氏（Syunsuke氏）による手描きオリジナルキャラクター。 テリー・ボガードのボイスを使用しているMUGEN1.0以降専用の旧バージョンと、 ドット・システム・ボイスを一新し、WinMUGENでも使用可能となった新バージョンが存在。 当初は触角のような眉毛をしていたが、新バージョンではWinMUGEN某配管工のような太い眉毛に変更されている。 陽気で心優しい苺の男の子。 仲間には臆病だが素直なバナナのバナータス、食いしん坊なリンゴのりん太郎、可愛いものが好きなオレンジのオレリーヌなどがいる。 性能 旧バージョンはシンプルな4ボタン方式。 「バーンナックル」「ライジングタックル」「パワーウェイブ」といったボイス元と同じ必殺技を繰り出す他、 何故かマリオの「ファイアボール」や「マリオトルネード」そっくりな技を体得している。 超必殺技は乱舞技の「ストロベルラッシュ」と、マリオト…もとい「ストロベルトルネード」の強化版「スーパートルネード」。 ただし、後者は恐ろしく低火力な上に当てて反確という死に技なので、ゲージはストロベルラッシュに回すのが無難だろう。 AIは搭載されていない。 DLは下記の動画から 新バージョンはDDR氏のコンプゲー『Saturday Mornin Mayhem』仕様の6ボタン方式。 旧バージョン同様マリオやテリーからリスペクトしたパワーウェイブやバーンナックル、 「スーパージャンプパンチ」といった技の他、ストライカーとしてバナータスとりん太郎を呼び出す事も可能。 超必殺技はマリオの最後の切りふだそっくりな「いちまるファイナル」、バスターウルフそっくりな「ストロベルバスター」。 この他、ブリス技や感電・燃焼・凍結といった特殊やられに加え、 Warner氏製キャラのフェイタリティにも対応しており、グリフィン氏の超必殺技を食らうと首がすっ飛んだりするので苦手な人は要注意。 AIはデフォルトで搭載されている。 出場大会 「[大会] [いちまる・ストロベル]」をタグに含むページは１つもありません。
https://w.atwiki.jp/gamemusicbest100/pages/3362.html
FANTAVISION 機種：PS2 作曲者：寺田創一 発売元：ソニー・コンピュータエンタテインメント 発売年：2000年 概要 打ち上げ花火を題材にしたシューティングパズルゲーム。 PS2黎明期の作品ながらも花火のグラフィックは今見てもとても綺麗。 ゲーム画面とよくマッチした寺田創一氏のラウンジミュージックも高い評価を得ている。 後に2人対戦モードを追加した廉価版『ふたりのファンタビジョン』が発売された。 収録曲(サウンドトラック順) 曲名 補足 順位 FANTAVISION OPENING SOUTHISLAND STAGE1,2 SUBSPACE STAGE3,4 MOONY STAGE5,6 夜151位 INFINITY STAGE7,8 STARMINE STARMINE EXPOSITOR DEMO COMFORT GAME OVER INTEGRAL EXPLAIN/STAFF INTEGRAL(ORGAN) SOUTHISLAND(CONTRARY) INFINITY(PRIMARY) MOONY(ELEMENTARY) FANTAVISION(REPRISE) FANTAVISIONオリジナル・サウンドトラック